home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part1 / 1321 < prev    next >
Encoding:
Internet Message Format  |  1996-08-06  |  3.5 KB
  1. Path: news1.h1.usa.pipeline.com!usenet
  2. From: grantp@usa.pipeline.com(Pete)
  3. Newsgroups: comp.lang.c++
  4. Subject: Re: C++ with Zapp vs. Delphi
  5. Date: 10 Jan 1996 12:09:50 GMT
  6. Organization: Pipeline USA
  7. Message-ID: <4d0aae$s9v@news1.usa.pipeline.com>
  8. References: <DBk8wg2yqjbB083yn@iaccess.za>
  9. NNTP-Posting-Host: pipe8.h1.usa.pipeline.com
  10. X-PipeUser: grantp
  11. X-PipeHub: usa.pipeline.com
  12. X-PipeGCOS: (Pete)
  13. X-Newsreader: Pipeline USA v3.3.0
  14.  
  15. On Jan 10, 1996 07:01:55 in article <Re: C++ with Zapp vs. Delphi>,
  16. 'vincer@iaccess.za (Vince Risi)' wrote: 
  17.  
  18.  
  19. Pete: 
  20. >> If the intent is to  compare language, then the proper pairing is 
  21. >> Pascal (or Object > Pascal) vs. C++. 
  22. > 
  23. >> If discussing development systems, Delphi vs. MSVC++ might be more 
  24. >> appropriate. 
  25. > 
  26. Vince: 
  27. >Not a fair comparison, perhaps Visual Basic or Powerbuilder vs Delphi 
  28. >as visual languages. 
  29. > 
  30. Agreed, but in the context of the subject line, MSVC++ & Delphi is 
  31. a more appropriate comparison. 
  32.  
  33. Pete: 
  34. >> In the first case; Pascal vs. C++;  C++ wins hands down. 
  35. > 
  36. Vince: 
  37. >Purely subjective and definitely spurious. As languages go they 
  38. >both have strength and weaknesses. 
  39. > 
  40. Very true.  I just believe that in producing complex systems (or even 
  41. just plain large), Delphi simply falls short.  Don't get me wrong, 
  42. I like Delphi and use it for what it's good for.  Likewise C++ systems. 
  43.  
  44. Pete: 
  45. >> Note that we are considering the languages with their respective 
  46. >> standard libraries.  Note also, that the comparison must include 
  47. >> the whole gamut of software production, not just simple school 
  48. >> projects or GUI-only front-ends. 
  49. > 
  50. Vince: 
  51. >Whats your point here? 
  52. > 
  53. The point is that many software packages are primaly front-ends to 
  54. databases or other servers.  Often the great majority of code in 
  55. such programs is involved in interacting with the user.  Delphi, 
  56. PowerBuilder, VB, and the like are the perfect tools for those 
  57. products.  Of course, you can build all of those front-ends with 
  58. C++ also, it just takes a little more time and effort. 
  59.  
  60. But try writing a complex math computation or systems that require 
  61. extensive memory management, and the others either can't do it at 
  62. all, are very clumsy at best, or run at snail's pace.  In other words, 
  63. C++ gives you all that Delphi et al give you, plus some. 
  64.  
  65. Pete: 
  66. >> In the second case, interpretation of "Powerful" must be established. 
  67. >> Assuming that "more powerful" means that a given amount of 
  68. >> source code or effort by the developer produces more functionality, 
  69. >> the two are actually quite close to one another.  Delphi wins in the 
  70. >> speed of GUI development arena.  MSVC++ wins in systems involving 
  71. >> much computation and data manipulation.  Also, C++ has capabilities 
  72. >> that Delphi simply doesn't have or are difficult to implement. 
  73. > 
  74. Vince: 
  75. >Specifically? 
  76.  
  77. Since I'm not an expert in Pascal, I may be wrong on this -- in fact, I 
  78. hope someone corrects me on this so that I can solve this problem :-) 
  79. -- I have found no way to dynamically allocate a specific amount of 
  80. memory in Pascal where the amount is determined at run time.  In other 
  81. words, I can't do the Pascal equivalent of this: 
  82.  
  83.      int siz = CountObjex(); 
  84.      Obj * pObjArray = new Obj[siz]; 
  85.  
  86. I know that I could use a container class that allocates a predetermined 
  87. (by the system) amount of space, then adds to it as it's needed, but 
  88. that's:   
  89.    1.  wasteful as siz may be 1, or even 0; 
  90.    2.  There's a good chance that, as the array grows, it has to 
  91.         reallocate memory, which involves copying -- needless runtime 
  92.        inefficiency. 
  93.  
  94. -- 
  95.  
  96. Pete
  97.